The present invention relates to a method for carrying out version control in the development of databases, in particular, but not exclusively, relational databases.
Various database models are known, including the hierarchical model, the network model and the relational model. The model most commonly used is the relational model.
Relational databases are databases in which relationships are identified in the different sets of data making up the database. FIG. 1 shows, in schematic form, a typical relational database structure. A relation defines a set of tuples, which represent an object and information about that object. The various tuples in the relation share the same attribute, and there may be several different attributes in the relation, as shown in the diagram. Stored data is manipulated using a programming language called Structured Query Language, or SQL. SQL is based on set theory, and relational operators such as “and”, “or”, “not”, etc., are used to perform operations on the data. The operations that can be used in a relational database include, e.g., “insert”, “select”, “update”, and “delete” privileges. The relational terms defined above have equivalent names in SQL, namely: “relation”=“table”, “tuple”=“row” and “attribute”=“column” in SQL. In addition, the relationships between the various components just described (tables, rows, columns) are commonly designated as the “schema”, which relates to the structure of the database. Thus, there are two parts of a database to be defined, namely the schema and the data associated with the schema, and these are both described by SQL language scripts.
It is common practice for a number of developers to be involved in the development of a database. Often the developers will all work on the same master database, which is kept on a master server. Unfortunately, this can create problems, since a first developer can make changes to the master database, which a second developer does not know about. Consequently, the second developer may well work on such a changed master database and find that the changes he makes cannot be committed to the master database, since the changes made by the first developer are not compatible with the second developer's changes.
In an attempt to mitigate this problem, it is known to interpose between the developers and the master database a database administrator, which imposes some order on the changes made to the master database. However, it takes time for such an administrator to perform its functions, so that a developer will be subject to a delay, before he can submit further changes to the master database.
An alternative known measure is for each developer to make a copy of the master database on his own local server. Changes are made to this local copy, then this changed local copy is compared with the master database and the various changes are then applied to the master database manually. This is time-consuming, and also prone to error.
It is desirable to be able to control in an automatic way how a database changes with regard to its various states or versions, so that any number of developers can make their own changes to the database and have these changes committed efficiently and without delay to the master database, while allowing each developer to readily update his own local copy of the database to a particular state or version.